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Abstract. We consider interactive coding in a setting where n parties wish to compute a joint 
function of their inputs via an interactive protocol over imperfect channels. We assume that 
adversarial errors can comprise a 0(1) fraction of the total communication, occurring anywhere 
on the communication network. Our goal is to maintain a constant multiplicative overhead in 
the total communication required, as compared to the error-free setting, and also to balance the 
workload over the different parties. We build upon the prior protocol of Jain, Kalai, and Lewko, 
but while that protocol relies on a single coordinator to shoulder a heavy burden throughout the 
protocol, we design a mechanism to pass the coordination duties from party to party, resulting 
in a more even distribution of communication over the course of the computation. 


1 Introduction 

The fundamental problem of errors in communication has been studied ever since the groundbreak¬ 
ing work of Shannon |Sha48] . Due to his results, we know how to construct error-correcting codes 
that achieve a constant information rate despite a constant error rate. In this paper, we study error 
correction in the interactive setting, an area that was introduced by Schulman |Sch92j . |Sch93j . In 
particular, we are interested in this problem in the multi-party setting. 

We note that it is insufficient to simply encode each message of the original interactive protocol 
with a traditional, non-interactive error-correcting code. In the case of adversarial noise, this will 
result in a poor error rate, since if k messages are sent in the protocol, the error-rate must be less than 
1/k. After all, we can not allow even a single message to be fully corrupted without compromising the 
correctness of the computation. 

In this work, we show how to convert any n-party interactive protocol into a new protocol that is 
resilient to 0( Infraction of adversarial error, while incurring only a constant blow-up in the commu¬ 
nication complexity CC. 

This is similar to the properties achieved by the protocol in [JKL15I . but we achieve a new addi¬ 
tional feature. Namely, |.TKL15] requires a single party to act as a “coordinator” of the entire computa¬ 
tion, and that party must individually perform a constant fraction of the overall total communication. 
In a distributed setting with n parties, we might naturally want the communication burden to be 
more equally distributed over the course of the protocol. To ease the burden of central coordination, 
we introduce new techniques that allow the role of the coordinator to be passed from party to party 
in a rotating fashion, equalizing the communication over time. Thus, we do not require that any one 
party Pi “lead” the computation for the entire time, and this avoids the resulting blowup in Pi s 
communication complexity. 


1.1 Prior Work in the Multiparty Setting 

Rajagopalan and Schulman IRS94] first extended the problem of error-resilient interactive coding to the 
multi-party setting, and showed how to achieve error-resilience against stochastic errors. When there 
are n parties communicating, their method has a communication complexity overhead of 0{n 2 logn). 
The original protocol is converted to one that proceeds in rounds such that every party Pi sends a 














message to all of its neighbors during each round. Therefore, if the original protocol is synchronous, 
i.e. 12(n 2 ) bits are transmitted per round, and there is a ©(log n)-factor overhead in the number of 
rounds. 

However, protocols are not always synchronous, an issue which Jain, Kalai, and Lewko addressed 
[JKL15] . They consider an arbitrary n-party protocol tt with static speaking order and at least one 
party P* who shares a communication link with all other parties. In this context, they present a 
compiler that converts tt into a new protocol n that is resilient to a ©( ^-fraction of adversarial errors 
and which incurs only a constant blow-up in the communication complexity. Jain et al. require that 
every party sends all of its outgoing messages in tt to P*, who delivers each message to its recipient, tt 
is thus restricted to pairwise interactions with P*, all of which are protected via a two-party interactive 
coding scheme. Whenever P* notices an error on a channel, he signals a rewind to every party. It is 
important to note, however, that if a party Pi is silent for too long a period, P* may not realize that 
there was an error on his channel with Pj, in which case the computation may continue, incorrectly, 
for an extended period of time. Therefore, Jain et al. intersperse phases during which the parties 
exchange regular protocol messages with “polling phases,” when P* checks in with each party about 
its current state. Though CC(tt) = c • CC(n) for some constant c, the increase in work required of P* 
is potentially undesireable. 


1.2 Our Results 


We present a compiler that converts any n-party protocol a new protocol that achieves a constant 
information rate and is resilient to a ©(^-fraction of adversarial errors. Moreover, our scheme does 
not incur a blowup in the communication complexity of any one party during the computation. We 
assume that the network is complete and that the speaking order in the noiseless protocol is static. 

Theorem 1. (Informal) There exists a compiler Comp and constants c > 1 and e £ (0,1) such 
that for any n-party protocol tt with static speaking order and complete communication links, Comp 
compiles tt into a new protocol It such that: 


1. CC(tt) = c ■ CC(tt). 

2. Protocol it is resilient to — -fraction of adversarial errors (with high probability). 


3. 


The communication complexity of any party Pi is 0 



Item 3. above only holds when the communication of the original protocol is balanced among the 
parties, and the base protocol of [ JKL15I can be suitably modified to preserve this, except for the 
undue burden it places on the coordinator. We discuss this in more detail in Section HPl 


Our Techniques In |JKL15I , the special party that coordinates the computation simulates the error-free 
computation and maintains a global view, rewinding when necessary to correct errors and frequently 
speaking with all other parties to detect any errors that have not yet been revealed. A natural idea 
for distributing the work of this special party is to break the computation into “chunks” (similar to 
IBK12] J and have a different party serve as the coordinator for each individual chunk simulation. The 
basic difficulty in implementing this approach is that we need a new mechanism for efficiently checking 
for past errors. In [BK12I . where chunks are also simulated individually, hashes of the entire simulated 
transcript so far are used to determine if the previous chunks have been properly simulated. If these 
hashes reveal inconsistencies in the old chunks, the simulation process rewinds and re-simulates older 
chunks under the discrepancies are resolved. This is crucial to success against a significant error rate, as 
many individual chunk simulations may be corrupted, and moving on from these and not periodically 
rechecking them will lead to an incorrect result. 

However, we cannot simply use hashes of the entire past transcript to check consistency as in 
[BK12) , because our chunk coordinator is now rotating, and does not have a full view of the past chunk 
simulations when it was not serving as the chunk coordinator. To address this issue without incurring 















a super-constant blowup in total communication, we apply hashing not to the naked transcripts, but 
to previous hashes concatenated with the most recent chunk transcript. These previous hashes can 
be passed from an old coordinator to a new one at each chunk without increasing the communication 
complexity by more than a constant factor. One subtlety in ensuring that the communication load 
per party remains balanced over time is that the same party may be asked for the same old hashes 
more than once as the protocol attempts to resimulate a particular chunk multiple times. We address 
this by allowing a party to refuse to communicate under certain circumstances and for the protocol 
to continue anyway via a timeout mechanism. Our analysis further shows that these refusals do not 
prevent our simulation from making progress when the error rate is suitably bounded. 

Ultimately, the compression of previous transcripts into iterated hashes plus the message passing 
of hashes between coordinators results in a more evenly distributed protocol without sacrificing total 
communication complexity or error rate (up to constant factors). We view this as a necessary first 
step in adapting and expanding multi-party interactive coding techniques to be more appropriate for a 
truly distributed setting. Ultimately, we would like to see such techniques extended to achieve stronger 
error-resilience for a wider variety of multi-party tasks, including classical distributed computing tasks 
like Byzantine agreement. 

1.3 Additional Related Work 

There have been several works improving on the (l/240)-fraction of adversarial of errors allowed by 
Shulman’s original (two party) protocol. Braverman and Rao improved significantly on the tolerable 
error rate, allowing i — e with a binary alphabet or | — e with a constant alphabet IBRllj . AGS13 
and |GHS14j have improved the error rates beyond ^ by leveraging adaptivity. 

Both of the compilers in |Sch93l and [BR11J rely on tree-codes, which we do not know how to 
construct or decode efficiently. Recent work has made progress toward the efficient construction of 
tree-codes. In the stochastic case, Gclles, Moitra, and Sahai IGMSlll showed that a weaker form of 
tree codes is sufficient, and thus improved on the protocols of |Sch92l . [Sch931 . and [RS94I . 

Brakerski and Kalai |BK12I considered the problem with adversarial error and presented an efficient 
version of Schulman’s compiler. |BN13j improved upon the computation complexity of Brakerski and 
Kalai’s construction. More recently, (GH14j provided a simple scheme for efficiently simulating any 
two-party protocol, achieving optimal communication and error rates. The works of |GH14IBE14j 
also consider list-decoding for interactive communication, while the works of IKR13IHael4l study the 
channel capacity for interactive communication. 

2 Preliminaries 

In this section, we fix notations and definitions that we will rely on throughout the paper. We will 
begin with description of the noiseless protocol and then move on to a description of the two-party 
protocol from |Sch93| and the multiparty protocol from IJKL15j , both of which we will rely on in our 
own construction. 

2.1 The Noiseless Protocol 

Let 7 T be the noiseless protocol for the n parties Pi,..., P n . We consider the case where each message 
in 7 r consists of a single bit, since this is the “hardest” case. Moreover, we assume that messages are 
sent sequentially, so that only when a party Pj receives a message from some Pj does Pi send a new 
message to some Pfc, as dictated by the static speaking order of n. We assume that the first party to 
speak in 7 r does so after receiving a dummy message. At any point during the computation of n when 
it is some Pi s turn to speak we can describe the next-message function NM^. Let X = xi,X 2 , ■ ■ ■ ,x n 
denote the inputs of Pi, P 2 ,..., P n and Be -1 = 61 ,..., be -1 denote the first i — 1 messages of 7 r. 
Finally, let transi be the partial protocol transcript observed by Pi. Then be = NMj^; transi). 


































Let L = CC(tt). The entire transcript of 7r corresponds to a unique path from the root to a leaf of 
a binary tree of depth L , which we will denote by T. Each node of T corresponds to a party Pi, and 
each arc corresponds to a message sent in n, either a 0 or a 1. If there is an arc from a node labeled Pj 
of depth £ to a node labeled Pk via an arc labeled b on the path in T corresponding to the transcript 
of 7 r, then the Lth message of 7r is the bit b sent from Pj to Pk- 


2.2 More Details of Our Model 

We consider an adversary that’s computationally unbounded and can flip bits anywhere. The adversary 
is only constrained to having a specific error budget over the lifetime of the protocol. 

In our measurement of communication complexity, we allow for a timeout mechanism, whereby 
a party that does not want to send requested information can signal that by not replying in a fixed 
amount of time. We do not count this in the communication complexity. 

Finally, William Hoza |Hozl4| observed that adding links between parties can be used to tolerate 
an arbitrarily high error-rate. If Alice and Bob are connected by two channels and the adversary cannot 
insert or delete bits, but only alter their contents, then Alice can communicate ‘0’ to Bob by only 
using the first channel, and ‘1’ by only using the second. In this way, Bob can decode Alice’s messages 
perfectly even without looking at the contents. We assume that there is only one path between parties, 
so we leave this as a topic for future work. 

2.3 Schulman’s Two-Party Compiler 

Here we give a brief overview of a slight variant on Schulman’s compiler ISch93l . as described in 
IJKL15] . Let 7 r = (Pi, P 2 ) be any two-party protocol. For the error-resilient protocol tt, 

Let 7 r be the noiseless protocol and T be the protocol tree for tt. For the error-resilient protocol 7 f, 
each party is equipped with a pebble «i which points to a node in T. T is padded to include dummy 
nodes at the bottom of the tree so that the height of the tree equals the length of the simulation. At 
any point, the movement of a, can be described by 0 , meaning that it moved down to the left child, 
1 , meaning that it moved down to the right child, H , meaning that it stayed put, and B , meaning 
that it moved back to the parent node. The movement of each pebble can be described by a 4-ary tree 
where each arc is labeled 0, 1, H or B. This 4-ary tree is called a history tree , and is denoted HT- 
The two parties also share a 4-ary tree code PC of depth N over an alphabet E of constant size c, 
which they use to encode and decode each others’ pebble movements. We are now ready to describe 
the steps taken by Pi upon receiving a message from P 2 , which are symmetric to those taken by P 2 
upon receipt of a message from Pi. 

1. Guess P 2 ’s pebble position: Let v = zq,..., Vk be the sequence of tree-code symbols Vj that 
Pi has received from P 2 so far. Pi guesses the history histi of pebble moves made by P 2 such 
that the hamming distance A(TC{hist 2 ,T ) is minimized. Pi uses hist 2 to compute 02 , its guess 
for P 2 ’s pebble position in T. 

2. Compute the next pebble move: There are several cases depending on the relative positions 
of eta and 82 . 

— If (\\ = 82 , then in Pi’s view, Pi and P 2 are in the same position in T. If it is Pi’s turn 
to speak, then he computes r = NMi(aa,trans), where trans is the concatenation of the arcs 
along the path from the root of T to eta. Otherwise, it is P 2 ’s turn to speak, in which case Pl 
sets t = H. 

— Otherwise, if aa is the parent of 82 and P 2 is the label of the node pointed to by an, then P 2 
has sent a message to Pi, and Pi should set r = 0 (respectively, 1) if 82 is the left (respectively, 
right) child of an. 

— Otherwise, if aa is an ancestor of 82 , then P 2 may have moved along an incorrect path in 7”. 
Therefore, Pl sets r = H and waits for P 2 to move back up the tree. 








— Otherwise, if the least common ancestor of oq and 5-2 is a strict ancestor of aq, then in Pi’s 
view, Pi and P 2 have diverged onto different paths in T. Therefore, Pi sets t = B in order to 
back up to the point of consistency in T■ 

Now that Pi has computed its next pebble move r, it moves a\ accordingly. 

3. Send next symbol to P 2 : Let histi be the history of Pi’s pebble moves made during the 
computation of 7 f. Pi computes v = TC(histi) where v = v 1 , ..., r/| histl |. Pi sends ^|histi| to P 2 . 


2.4 Jain et al.’s Multi-Party Compiler 

First, we give the main theorem from |JKL15| and then give a high-level overview of their compiler. 

Theorem 2 ( }JKL15) 1. There exists a compiler Comp and constants c > 1 and e' £ (0,1) such that 
for any n-party protocol tt' = (Pi,... , P„), with static speaking order and at least one party Pi that 
shares a communication link with all parties {Pj}j^H- Comp compiles tt' into a new protocol it' such 
that: 

1. CC(H') =c-CC( tt'). 

2. it' is resilient to (—)— fraction of (adversarial) errors in the total communication. 

3. The runtime of each party Pi is at most 2°^ n ' Cmax \ where Cmax is the maximum number of bits 

sent and received by any party Pj in the underlying protocol tt' . 

Jain et al. designate one party P* who shares a communication link with all other parties to “lead” 
the protocol. The network operates as a star network with P* as the hub node, tt' is thus decomposed 
into pairwise protocols 7Ti,..., 7r n where 7 q denotes the two-party protocol for communication between 
P* and Pi. P* shares the protocol tree % for 7 q with each Pi. P*’s copy of this tree is denoted 71*. 

|JKL15| splits the simulation of 7 r into a sequence of phases. The phases alternate between protocol 
phases and polling phases. 0(n) bits are exchanged during each phase. During the protocol phases, 
each Pi follows the two-party protocol simulation strategy, since he is only communicating through 
P*. Meanwhile, every time P* receives a message, he computes the “global consistency point” in the 
protocol tree T for tt. If this is further up the tree than the current node of the simulation, then P* 
signals a rewind, telling parties to back up until every party has returned to the section of P that 
is error free. During the polling phases, each party Pi sends a tree code symbol indicating its pebble 
position in the two-party protocol tree for 7 q. Therefore, if some party speaks much less often compared 
to other parties, an error in his computation history will still be detected in a timely manner. 

In order to achieve an overall balance of communication among the players, we will need to use a 
variant of |JKL15l ’s compiler that achieves such a balance, up to the imbalanced burden played on 
the special coordinator P*. Naturally, one cannot hope to achieve a constant multiplicative overhead 
in the total communication complexity and aO(^) relative complexity for each party if the original 
(noiseless) protocol does not have balanced communication. However, even when the original protocol 
does have relatively balanced communication complexity over the n parties, the protocol of jJKL15j 
does not preserve this. The glaringly obvious violation is the disproportionate burden on P*, but 
there is a more subtle potential violation as well. As P* attempts to simulate the error-free transcript 
during the non-polling phases of the protocol, it may adaptively speak with whatever party it deems 
relevant based on its current (possibly wrong) view, potentially causing communication to become 
unbalanced among the regular parties. 

There are several cases in which this undesirable behavior of the |JKL15| protocol can be avoided. 
One case is if the underlying (noiseless) protocol is actually synchronous, proceeding in rounds in 
which each party sends the same number of bits. In such a setting, P* can simply collect the messages 
from all parties for each round and simulate rounds in a balanced way. Polling phases can then be 
eliminated and the analysis given in IJKL15I to ensure successful simulation with an error rate of 
@(i) and a constant multiplicative overhead in total communication complexity still applies. 
















Another case is where the underlying protocol is asynchronous, but proceeds in balanced windows 
of communication where each party speaks once (and sends the same number of bits). For example, 
consider a protocol that consists of P\ sending a bit, then P 2 , then P 3 , and so on, simply going through 
the parties one by one in a fixed order. The coordinator P* of the |JKL15l protocol could then proceed 
to speak with parties in this same ordering, and again separate polling phases could be eliminated. 

More precisely, the P* in this case will still maintain a view of a “global consistency point” in the 
overall protocol tree where he believes the other parties need to rewind too, but he will work in units 
that correspond to the communication windows and stick to the fixed speaking order while attempting 
to rewind parties back to this point and learn new information (so the global consistency point will 
always be defined as the beginning of a window). Intuitively, since the |JKL15l protocol can tolerate 
waiting for a polling phase for P* to speak to a particular party and discover a previous error, this 
approach can also tolerate a@(j) error rate. 

To see this more formally, we can tweak the analysis given in (,TKL15j by defining an adjusted 
measure of progress. Our measure M could be defined (in window units) as follows. We let depth(gcp) 
denote the window index of the true global consistency point in the noiseless n-party protocol tree. 
For each party Pi, we let d(i,gcp) denote the number of number of windows away from gcp that P*' s 
and Pi s pebbles are in their 2-party simulation. We then define: 

M := depth(gcp) — max{d(f, gcp)} 
i€[n] 


Analogously to [.TKL15I , we can then define a good window as a window where all the symbols are 
received correctly by P* and each party Pi and that all parties have correctly guessed the positions 
of all pebbles. In such a window, we claim that M will strictly increase. To see this, we note that if 
d(i,gcp ) = 0 for all i , then P* will successfully simulate a new window, and depth(gcp) will increase. 
If d{i,gcp) > 0 for some values of i , all of these parties will move their pebbles appropriately during 
the window in order to decrease max i£ i n ]{d[i, gcp)}. 

We similarly claim that any non-good window can only decrease M by a constant amount. First, 
it is clear that depth(gcp) can only change by a constant amount, and since d(i,gcp) only changes by 
a constant amount for each i, the max can also only change by a constant. 

Now an analysis common to 1.IKL151 and |Sch92j easily applies: we can take every non-good window 
and argue that it is contained in a bad interval that contains a I2(i) fraction of errors. If any symbol in 
the window itself is corrupted, then that window serves as a suitable bad interval (since 0(n) symbols 
are sent per window). Otherwise, the constant rate of the tree code and the fact that every party 
sends one symbol per window means that we take a backward-stretching interval including a number 
of windows proportional to the depth of the worst tree-decoding error as a suitable bad interval. As in 
f.TKF15| . we can then see that a constant multiplicative overhead in the number of window simulations 
then suffices to insure a correct simulation of the underlying protocol. 

It is worth noting that our approach for passing off the duties of P* from party to party is rather 
modular, and does not depend upon the precise details of how P* simulates a piece of the protocol. 
Thus, other variants of |JKL15| or other base protocols that equalize communication complexity 
among parties except for a heavy burden on P* could also be inserted into our protocol to obtain 
analogous results. 


2.5 Hash Functions 

We use a family of hash functions index by keys k £ {0, l} 4 . In particular, we invoke the following 
theorem of [NN93j . A(II 11*92 . 

Theorem 3. llNN93f . \AGHP9Sf l There exists a constant q > 0 and an ensemble of hash families 
and an ensemble of hash families {Hn}ngn such that for every N £ N and for every h £ Hn, 
h : {0,1}- 2 — > (0, l} ?Ar is poly-time computable, it is efficient to sample h £- Hjy using only qN 


























random bits, and for all y ^ z £ { 0 , 1}— 2 it holds that 


Pr [ h(y ) = h(z)\ < 2~ N . 

h<—HN 

We set t = qN and write hk : {0, l}- 2 ” —>• {0,1}* to denote the element of if at sampled with 
the random string k G {0,1}*. We also let {Enci,-Deci} and {Enc 2 ,DeC 2 } denote two pairs of 
encoding and decoding algorithms of error-correcting codes with constant rates /3 and a constant 
relative distance A. In particular, we have 

End ■ {0, l} 2t ->■ {0,l} 2/3t 

and 

Enc 2 : {0,l} nt {O,!}' 3 "*. 


3 Our Compiler 

3.1 Overview 


Our compiler consists of two main phases: chunk simulations and consistency checks. These two phases 
make up a single “iteration” of i f. A chunk refers to a section of T such that the chunk indexed by j 
includes all nodes in T of depth greater than or equal to jk and less than (j + 1 )k for a parameter 
k that we will define. The parties will sequentially take turns serving as P * for a chunk simulation, 
during which time the protocol from 1.1 K 1.151 (adapted as described in Section HOI) will be run. Each 
Pi is equipped with variable 7 j, set to 0 at the beginning of the protocol execution, which indicates 
the chunk that the party is currently simulating. Also, as in |JKL15j . each party is equipped with a 
pebble a, which points to the root of 77, as well as pebbles af* with which to lead the simulation 
during their turn as P*. 

During the consistency checks, the parties ensure that they are all simulating the same chunk of 
P and they rewind if they are out of sync. If there is a rewind, the new leader P new * must be able 
to request information from the old leader P 0 u* who led the simulation during the chunk P new * has 
backed up to. We later refer to this as “tapping” P 0 id*- Pnew* must have a way of checking that the 
entire computation of tt has been correct, even though he was not the leader for most of the chunks. 
Therefore, we require each party to store information about the computation of each chunk so that 
they can ensure the correctness of the simulation so far. This data, which we will describe in detail 
later in this section, is stored in a vector, which we call pi for each Pi. Pfs data regarding the jth 
chunk of T is stored in p, [y ]. Pi may write over data stored in any Pi[j] if the j th chunk of T is 
simulated multiple times during the computation. 

Let CC(tt) = L. The simulation is stopped after a total of 5 L symbols have been exchanged. We 
let m be a constant positive integer such that it takes mk exchanges to simulate a chunk using the 
protocol from | JKL15j . There are at least 4n/3t bits exchanged during the remainder of an iteration 
of 7 r, where (d is the constant rate of the encoding algorithms and t is the length of the hash function 
output. We set 4n/dt = mk, so that the number of bits exchanged during the simulation of a chunk via 
the protocol in | JKL15j is at least the number of bits exchanged during the remainder of an iteration 
in tt. Therefore, k, the depth of each chunk, is set to be 4 nfdt/m. 

At the beginning of a chunk, P* will begin communication with the Pk that is the label of the first 
node of the chunk in 77 For the remainder of the chunk simulation, communication among parties 
will follow the protocol described in [JKL15 ;. 

We will first describe the initial iteration of n and then an arbitrary j th iteration of 7 r for j > 1. 












3.2 The first iteration 


Pi, as P*, will progress through the first chunk of T, following the protocol described in [ JKL15] . 

Now we give a high level overview of the first consistency check. Each Pi hashes his transcript from 7) 
and stores it in pi [0]. In the next iteration, he will concatenate this hashed value with the transcript 
from the second chunk and store it in p;[l], and so on. During the consistency check, each party Pi 
sends this hashed value to P* and P* computes his own version of this hash value for each Pi . If the 
hashed values all match up with P*’s n computed values, then P* sends P (“forward”) to each party. 
Otherwise, P* tells the parties to back up to the beginning of the chunk by sending PI (“back up 
one chunk”) to each party. (In future iterations, P* may send P2 to a party Pi in order to have the 
party back up to chunk number £ — 1 if y* = £.) Specifically, the following steps occur during the first 
consistency check: 

1. Each Pi computes its hash value and sends it and 7 j to P*: For all i £ [2, • • • , n], let oyo 
be the local transcript of the two-party protocol in p corresponding to the first chunk of T. Set 
ipi.o '■= Pi samples ki <— H and sends Enci(H ki (ifi,o) II h) to P*. We denote received hash 
values by adding a tilde above the H, so we say that P* receives H ki (V 70 ) from each Pi. 

2. P* computes its corresponding hash value: For all i £ [2, • • • , n], let V’i.o* be P*’s local 
transcript of the two-party protocol in the first chunk of 7)*. P* computes the corresponding 

H k Mi, o*)- 

3. P* compares the hash values: We say that the chunk was good if for all i, H ki (i/y.o) = 
PfciW’i,o*)- Otherwise, we say the chunk was bad. 

4. The parties store their hash values: For all i £ [2,... ,n], Pi stores in Pi. [0] and Pi, 

who is acting as P*, stores {{H ki (V’i.o*)}, H kl (^ 1 , 0 )} in pi[ 0 ] , where {H ki (^ i)0 *)} = {7/fc, (^ 1 , 0 *), 
P fc2 (V> 2 , 0 *),-, H kn (iP „ i0 *)}. 

5. P* directs the parties to move forward or rewind: If the chunk was good, P* sends Enc\{F) 
to each Pi, and Pl increments 71 . Otherwise, P* sends Enci(Bl) to each Pi. 

6 . Each party updates its chunk and pebble: For all i £ [2,...,n], let Xi be the symbol Pi 
received from P* in StepO depending on whether the chunk was good or bad. Now, each P* sets 
7 i <— chunkUpdate( 7 fi, 7 j, a*). 

chunk(Jpdate(W, 7 i, an ): 

— If Xi = F, then increment 7 p 

— If Xi = PI, then set at to point to the first node in 7) that is a node in the 7 jth chunk. 

— If Xi = B 2, then set cti to point to the first node in 7) that is a node in the ( 7 * — l)th chunk in 
Ti- Then decrement 7 *. 


3.3 The jth iteration 

Chunk Simulation Suppose it is P^s turn to act as P*. Let s be the index of the chunk of T that 
Pi will simulate. First, each Pi sends Enc\(^i) to P*, which it decodes using Dec\. Either 7 * = s for 
all i, or there is some i for which the two values differ, and P* acts accordingly: 

— If 7 ,: = .s for all i, then P* requests {H ki (a ijS _i*)} from the party it believes acted as P* during 
the simulation of chunk number s — 1 , say P k during time interval j. P * will request this set of 
hashes by sending Enc\{j ) to P k . If P k has already sent this set of hashes during a different chunk 
simulation, then he will ignore this message from P *. This is crucial to prove the third part of 
Theorem[T] Otherwise, he will send Enc 2 ({H ki (ai iS _i*)}) to P*. 

Meanwhile, P* will wait a specified amount of time for P k to respond to his message. If P* does 
not receive the set of hashes, then the transaction has “timed out,” and P* sends garbage symbols 
for the entirety of the chunk simulation. Otherwise, P* receives the set of hashes from P k , and 
P* leads the chunk simulation following the protocol described in |JKL15j . 

— If 7 i s for some i, then there is no way for the chunk simulation to be successful. Therefore, P* 
sends garbage symbols for the entirety of the chunk simulation. 







Consistency Check After the chunk simulation, the following set of computations and exchanges 
will occur. 

1. Each party Pi computes its hash value: Let 07 7i be the local transcript of the two-party 
protocol in 7) corresponding to the y^th chunk of T. Set 

= °*i7i II PiYli ~ I]' 

Then P, then samples hi t— H and sends Enci ) || hi) to P* and sets Pil'ji] = 

2. P * computes its corresponding hash value: For each i £ {1,..., n}, P* creates its version of 

the concatenated transcripts it received from P t . Recall that at the beginning of the iteration, P * 
may have received the set {H^ i*)}, where from the party that P* believes most recently 

led the computation of chunk number s — 1 of 77 (Here we use fcj to denote the key sampled by 
each Pi during the previous iteration in question.) If P* didn’t receive this set of hashes, either 
because it did not ask or because the operation timed out, then it skips to Step [4] and stores 
garbage values in pi[s). Otherwise, let < 7 j iS * be P*’s local transcript from the two-party protocol 
in Tj* corresponding to chunk number s of 77 Set 

1pi,s* = Vi,s* || -Hfc. (V’i.s-l*)- 

Then P* applies the hash function Hu to ibj ,* to get Hu. (tb, *). Since Pc is currently acting as 
P*, it stores {{H ki (ip i>s *)}? =1 , H ke (i[)^)} in p e [s\. 

3. P* compares the hash values: If H^^i s) = (V’qs*) for all i £ {1,.. . n}, then this chunk 

was good. Otherwise, it was bad. 

4. P * directs the parties to move forward or rewind: If the chunk was good, then P* sends 
Enci(F) to each P^, and Pg increments 7 ^. 

Otherwise, the chunk was bad. Recall that at the beginning of the chunk simulation, each Pi 
sent Enci{^i) to P*. Let eg be the smallest value of 7 , for all i £ {l,...,n}, as computed 
by P*. If 7 i = cp and Hk^tpi^) = then P* sends Enci(Bl) to Pi. Otherwise, P* 

sends Enc\(B2) to Pi. Finally Pf = P* sets 7 ^ <— chunkUpdate(Pl, 7 ^, at) if cp = 7 £ and 7 ^ ■<— 
chunkllpdate(P2, 7 ^, Of) otherwise. 

5. Each party updates its chunk and pebble: For all i £ {1 ,... ,n}\ {£}, let Xi be the symbol 
Pi received from P* in SteplU Now each Pi sets 7 , •<— chunkllpdate(Xi, 7 $, a*). 

4 Measuring Progress 

In the following section, we prove the success of our simulation conditioned on the event that there 
are no hash collisions over the course of the computation. Since there are ^4^ hash values computed 
over the course of the simulation, by Theorem [3] and a union bound, the probability that there is no 
hash collision at any point during the computation is at least 

1 _ . 2~ n 

k 

Therefore, if we want to ensure the success of the simulation with probability 1 — 2 _T for some 7 , we 
can set 

N > 7 + log(5nP). 

t = qN is set accordingly. 

Now, we must define a measure of progress that we can compute at each iteration during the 
protocol. We will show that by the end of the simulation, the measure of progress is sufficiently high 
as to ensure success. To this end, let £ be the node in T where the first error occurred. Say £ is in 
chunk cj. Now, let cp be the chunk such that: 



^/3 ^ , 

— the party who most recently led the correct simulation cp has not yet been tapped for the set of 
hashes from cp, and 

— for all chunks Ck < cp, every party is in agreement about which party simulated Ck most recently 
and during which time interval the simulation occurred. 

Intuitively, if there have been errors, cp is the chunk that all of the parties must back up to in order 
to continue the correct simulation of tt. Recall that we equip each party Pj with a variable 7 j that 
allows them to keep track of which chunk of P he thinks the protocol execution is currently in. 

We are concerned with two types of error: 

1. External chunk error: For some j £ [1,..., n], 7 , ^ cp. 

2. Internal chunk error: For all j £ [1,... ,n], 7 j = cp, but errors have occurred in the execution 
of chunk cp. 

Suppose that there are external chunk errors. Let Pj be the party “furthest ahead” of the other 
parties, so 7 j > 7 *, for all k ^ j. Then there must be at least 7 j — cp consistency checks before all 
parties have backed up to chunk cp, and can start making progress again. Therefore, we define the 
measure of progress to be 

M = cp — (jj - cp) = 2cp - 7 j. 

First, we give a lower bound on the number of errors injected in an iteration that could cause M to 
decrease. Let e' be the constant from Theorem^ such that the protocol in IJKL15] is resilient to an In¬ 
fraction of error. Recall that the smallest codeword sent outside of the chunk simulation protocol from 
|JKL15j in any iteration of if is 2/3t bits, and that our encoding and decoding algorithms have constant 
relative distance A. Then it takes 2A f3t bit flips to corrupt one word, and since there are at most 10 n/3t 
bits exchanged outside of the I JKL15I protocol in each iteration, these exchanges are resilient to a 
■^■-fraction of errors. Therefore, if we set e = minje', A/5}, then both the chunk simulation protocol 
and the other exchanges during the iteration are resilient to an ^-fraction of errors. 

To prove the correctness of the simulation, we first analyze the change in M during “good” and 
“bad” iterations. We say that an iteration is good if the subprotocol from |.IKL15| is not overwhelmed 
by errors and if every party correctly decodes every other message sent during the iteration. Otherwise, 
we say the iteration is bad. 

Throughout the following analysis, let Pj be the party with a maximum 7 j value. 

Claim. A good iteration increases M by at least 1. 

Proof. If 7 j = cp, then a good iteration will increment cp, so M will increase by 1. If 7 j ^ cp, then 
Pj will decrement 7 j by 1. In this case, cp will remain the same. To see this, note that if there is any 
discrepancy among the parties regarding their 7 values, then P* will not request the set of hashes 
from any party, so cp will not shift. Moreover, if 7 $ = 7 ^ for all i,k £ [1,..., n], then P* may request a 
hash set from a previous P*, but since cp, that exchange will not effect the value of cp. Therefore, 
M will increase by 1. 

Claim. If the iteration is bad, M will decrease by at most 3. 

Proof, cp may move back by at most one during any iteration. This may happen in the case that 
either 

— Some Pj such that 7 j = cp jumps back when he should hold. In this case cp decreases by 1. 

— The party who had most recently led the correct simulation of cp was tapped for his hashes, and 
therefore will never send them again. If the simulation of cp is not successful, then cp will decrease 
by one. 










Also, 7 j can increase by at most one during any iteration, in the case where Pj, or some Pk such 
that 7 k = 7 j, moves forward when he should jump back. 

Therefore, M decreases by at most 3. 


We are now ready to prove the resiliency of our simulation. 
Lemma 1 . When running i r over a channel that makes at most 

5 eL 


E = 


8 n 


adversarial errors, n correctly simulates n. 


Proof. The simulation is stopped after a total of 5 L symbols have been exchanged, where C'C'( 7 r) = L. 
Recall that k is the depth of a chunk and m is a constant positive integer such that it takes mk 
exchanges to simulate a chunk via the protocol in IJKL15I and at least Anfdt = mk exchanges to 
complete the remainder of an interaction in 7 f. We will show that 

L 

Cf> i 

by the end of the simulation, ensuring its correctness. To this end, we define the potential function 

4t7< 

<p = (2cfl - 7 j)k H- E. 

em 

(We abuse notation above and use E to refer to an accumulating variable for the number of errors so 
far in the computation.) 

Let denote the change in p in iteration £, £ G {1,...,^}. We claim that pe > k for all £. 
From Claim [4] we know that if iteration l is good, then M = 2 cp — 7 j increases by one, so ipe > k. 
Meanwhile, if iteration l is bad, then M decreases by at most three. However, this means that there 
were at least errors, enough to overwhelm the chunk simulation protocol from |JKL15j . the other 
exchanges that occurred during the £th iteration, or both. Therefore, E increased by at least ) so 

tpt > —3 k + 4 k = k. 

Since there are iterations during the simulation, p > 5L by the time it finishes. Now, we know 
that at the end of the simulation, {2cp — 7 j)k > 5L/2 or —E > 5L/2. However, the latter would 
imply that 

„ 5 eLm 5 eL 

E > - > -, 

8 n 8 n 

which is a contradiction. Therefore, 

5L 

— < ( 2 cp - 7 j)k < 2 cpk, 
so 

as desired 


L 5 L 

~k < ik- Cfh 


We conclude with a proof of Theorem [T] 

Proof (Proof (Theorem QJ)^. The first part of Theorem [T] is clear by construction, since we require 
that CC(fn) = 5 L = 5CC(tt). The second part of Theorem [Q follows from Lemma Q] Finally, each 
party will be required to serve as P* for no more than |"|^] chunks and also must forward his hash 
sets to another P* no more than |"f^l times. Therefore, the increase in communication required when 
simulating 7 r is split evenly among the parties, so the communication complexity of any party Pi is 
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